I don't think using "nil" is clear here. Also, this is ambiguous. If I have only a single string with spaces but no nil, it is impossible to determine if I have some\ command\ with/spacesinpath and no arguments, or a GetCommandLineW-encoded command line.

There is also concern around using two different data types to represent the same attribute value: #635 (comment). It might create additional complexity on back end systems to have to manage potentially different data types for the same attribute, though I'm not sure how much of a concern this would be? I guess parsing null-characters on the back end would likely be equivalently complex.

Note this isn't strictly ambiguous btw. If that was a command with no arguments, and you were looking at the Unix representation, it would have a null-character as the last character in the string. On Windows it would not. Admittedly that is not a great representational difference, and could be difficult to distinguish in some programming languages.

After thinking about this some more, I think I do prefer the list of strings approach, but I'm not sure I'm aware of all the pros/cons. For now I have changed it back to that, and updated the example for each OS accordingly. But for the record here's the three options considered and pros/cons:

1. Join arguments with a string:
   Advantages: Most consistent representation across OSs.
   Disadvantages: Potentially lossy/non-trivial conversion on Unix - do we need to enquote parameters with spaces in them (and escape internal quotes), etc?
2. Pass through string returned from OS as is (null-delimited on Unix):
   Advantages: No processing needed by code producing telemetry, can just provide what OS returns.
   Disadvantages: Back end needs to parse null-characters.
3. Convert to list of strings (for Unix only):
   Advantages: Clean ("properly typed") representation.
   Disadvantages: Inconsistent data type for the same attribute between OSs, and back end needs to handle this differently.

FYI @arminru note I've reverted the changes based on your last comment since you approved. Please take another look.

@igorpeshansky you may also be interested.

Interestingly ps on Mac and Linux doesn't appear to apply any quoting so if there are spaces or quotes in in your argument (e.g. app --set "foo bar") ps doesn't appear to quote them. We could quote them (https://godoc.org/github.com/gonuts/go-shellquote#Join [1]). I can't think of any downsides in particular when it comes to filtering on quoted values. I think in most cases you're not going to be doing filtering on values that have quotes in them or other escaped characters. I imagine the common case is you're searching for commands that have basic things like "repl-factor" or some such in it.

[1] Not endorsing it, just searched for a shell escape library in go.

I usually see commandline as two words. Do we want to build naming hierarchy here as well? Or, just insert a separator?

Changed this to process.command_line for now. I'm not sure if process.command.name would be a reasonable name for the "command"

SGTM 👍